MBS Script Search

mbs-script-search is a focused search UI for FileMaker/MBS script XML exports. It loads a Base64-encoded XML source, builds a client-side search index, and lets you search script names, script IDs, group paths, script steps, and step arguments from one interface.

The project is built with Vite and packaged as a single-file web app for easy embedding and deployment.

User Guide

What the search can find

The search can match in these areas:

Script names
Script IDs
Group paths
Script steps
Step contents / arguments

Each result groups all matches per script, so one script can show multiple matching areas at once.

How to search

Type into the search field to search immediately. Input is debounced slightly, so the app waits a short moment before running the search.

The search is normalized before matching:

Case-insensitive
Accent/diacritic-insensitive
Whitespace-normalized
Segment-aware for values like CamelCase, underscores, paths, and mixed letters/numbers

This means many common formatting differences are ignored automatically.

You can override the default case-insensitive behavior with the Case-sensitive search checkbox in the actions menu.

Search logic: `Exact` vs `Tolerant`

These buttons control how strictly terms are matched.

They apply only when the query mode is set to Text and case-sensitive search is not active.

`Exact`

Exact means no fuzzy typo matching is applied.

It still benefits from the app’s normalization and token segmentation, so it is not “case-sensitive exact” in the strict literal sense. In practice, Exact means:

No typo tolerance
Normalized matching still applies
Prefix matching can still help while typing
Custom app-side validation still shapes the final result list

Use Exact when you know the term, function name, script name, or ID closely enough and want tighter results.

`Tolerant`

Tolerant is the broader MiniSearch-driven mode.

multi-word queries are supported
prefix matching stays active
fuzzy matching can apply per term
short terms are still protected from fuzzy matching

In practice, Tolerant uses MiniSearch more directly, especially for script names, IDs, paths, and individual step areas. This means tolerant mode is much better suited for:

typo-tolerant queries
exploratory searching
broader phrase searches with multiple words
mixed prefix/fuzzy matching behavior while typing

Examples:

SetVarible may still find Set Variable
set varible excel can now work as a tolerant multi-word query
short terms are not fuzzified
numeric terms still receive ID-oriented ranking rather than aggressive fuzzy behavior

Use Tolerant when you want MiniSearch to do the broader work for you.

Query mode: `Text` vs `Regex`

These buttons control how the content of the search field is interpreted.

`Text`

Text is the default mode.

In this mode, the app uses the existing normalized text search pipeline together with the selected Exact or Tolerant logic and the selected All or Any term mode.

If Case-sensitive search is enabled, Text mode switches to a case-sensitive exact matching path and Tolerant becomes inactive.

`Regex`

Regex treats the search field as a JavaScript regular expression.

In this mode:

the pattern is evaluated directly against script names, IDs, paths, and step content
Logic and Terms are visible but inactive because they do not apply to regex matching
invalid regex patterns are reported immediately in the result area
the regex can be entered either as a plain pattern or as a literal like /pattern/gi
if Case-sensitive search is enabled, regex matching is forced to be case-sensitive
zero-width-only regexes are rejected before search runs

Use Regex when you need advanced pattern matching that is more precise than text search.

Examples:

Set\s+Variable
- finds Set Variable with flexible spacing
- good starter pattern for command-like step names
\b(?:Import|Export)\b
- finds either Import or Export
- useful for alternatives
^If\b
- finds text that starts with If
- useful for step labels or lines that begin with a specific command
\b[A-Z]{2,}_\d+\b
- finds values like FOO_123
- useful for technical identifiers
(?=.*excel)(?=.*import)
- rejected because it is a zero-width-only lookahead pattern
- this example will not produce results in the app
excel[\s\S]*import|import[\s\S]*excel
- finds text that contains excel followed by import or vice versa
- useful for finding text that contains both terms in any order

Practical notes:

entering a plain pattern like set\s+variable uses the app default regex flags
entering a literal like /set\s+variable/i uses the flags you provide explicitly
entering /set\s+variable/ without i is case-sensitive
if Case-sensitive search is enabled, the i flag is ignored so regex matching stays case-sensitive
zero-width-only patterns such as pure lookahead or lookbehind combinations are rejected with an error before search starts

Highlighting note:

highlighting marks the text actually consumed by the regex match
zero-width-only expressions such as pure lookaheads, pure lookbehinds, and boundary-only combinations are not allowed
if you want both matching and visible highlighting, use a pattern that consumes text, for example excel.*import or excel[\s\S]*import|import[\s\S]*excel

Term mode: `All` vs `Any`

These buttons control how multiple search terms are combined.

They apply only when the query mode is set to Text.

They still apply when case-sensitive text search is active.

`All`

All query terms must match.

In practice, the current implementation requires all terms to be found within the same searchable area, for example:

all terms inside the script name
all terms inside the path
all terms inside the same step content

This behavior is preserved in both Exact and Tolerant mode.

Use All to narrow the result list when you know multiple parts of the target text.

`Any`

Any one of the entered terms may match.

This is broader and helpful when:

you are exploring
you want variant matches
you are not sure which term will exist in the XML

This behavior is also preserved in both Exact and Tolerant mode.

Filters

After searching, you can reduce visible matches using the filter chips:

All
Names
IDs
Steps
Paths

The chips also show counts, so you can see how many matches belong to each category.

Result behavior

Results support several interaction modes:

Grouped by script
Path shown as context header
Matched terms highlighted
Disabled steps retained as matches
Hide All / Show All for the current visible result set
Progressive loading with Show more

The summary line below the toolbar reports loading state, match counts, and empty states.

Actions menu

The vertical three-dot button opens a native browser popover. It currently contains:

Hide All / Show All
Copy results
Summarized results only checkbox
Case-sensitive search checkbox

The action buttons are configured to close the popover after a short delay, so transient button feedback remains visible. The checkboxes do not close the popover.

Copying results

Copy results copies the currently visible result set to the clipboard.

Full copy mode

If Summarized results only is not checked, each step is copied with full text:

  - Set Variable - Line 41: full step content here

Summarized copy mode

If Summarized results only is checked, step matches are copied in a condensed two-line format:

  - Set Variable - Line 41
  - Contents: shortened preview here

This is useful when you want compact output without losing the step identity.

Technical Reference

Runtime flow

The app starts in src/main.js, mounts the UI, then loads and indexes the XML data.

High-level flow:

src/main.js mounts mountScriptSearchApp()
Base64 XML is loaded from the search data module
XML is decoded and sanitized
Script nodes are collected from the XML
MiniSearch index entries are built
Searches run entirely client-side in the browser

Data source

The current data source is imported from:

src/searchData.js (or src/searchData_mbs.js for MBS-specific data)

The exported variable is:

SCRIPTS_XML_BASE64

The XML is:

Base64-decoded
whitespace-normalized
sanitized to remove invalid XML control characters
parsed with DOMParser

Search index design

The index is built with MiniSearch.

Indexed fields:

scriptId
name
path
stepContent

Stored fields:

id
scriptId
name
path

Each script contributes:

script metadata
group name
full group path
all step entries
normalized searchable versions of all relevant text

Matching behavior in more detail

The current implementation combines several matching layers:

Query mode selection
- Text uses the standard search pipeline
- Regex uses direct JavaScript regular expression matching
Case sensitivity
- by default, text search remains case-insensitive
- enabling Case-sensitive search switches text search to a direct case-sensitive matching path
- when enabled in Regex mode, regex matching is forced to be case-sensitive
Normalization
- lowercases text
- removes diacritics
- collapses whitespace
Segmentation
- splits camelCase
- splits letter/number boundaries
- splits separators like _, ., /, \\, >, -
Prefix support
- enabled for terms with a minimum length threshold
Fuzzy support
- enabled only in Tolerant mode
- evaluated per term
- available for multi-word queries
- short terms remain excluded from fuzzy matching
Post-filter validation
- Exact mode still uses stricter app-side validation and contains-style fallback matching
- Tolerant mode relies more directly on MiniSearch result behavior through a dedicated area-based index
- Regex mode bypasses the text query logic and evaluates patterns directly against searchable areas
- case-sensitive text search uses a direct scan instead of the tolerant MiniSearch path

Scoring and ranking

The current score boost configuration favors these fields:

Script name most strongly
Script ID strongly, especially for numeric ID-like searches
Step content moderately
Path less strongly

This keeps likely script hits near the top while still surfacing deep step matches.

UI structure

Main UI responsibilities:

src/main.js
- app bootstrap
src/scriptSearchApp.js
- parsing
- indexing
- search behavior
- result formatting
- toolbar and popover interactions
src/style.css
- layout
- toolbar styling
- result cards
- responsive behavior
- native popover presentation

Configurable constants

These constants currently influence behavior directly in src/scriptSearchApp.js:

Constant	Current value	Effect
`PAGE_SIZE`	`100`	Number of result groups initially rendered before `Show more` is used.
`SEARCH_INPUT_DEBOUNCE_MS`	`120`	Delay before the search runs after typing.
`INDEX_BATCH_SIZE`	`20`	Number of scripts indexed per async batch.
`MIN_PREFIX_TERM_LENGTH`	`2`	Minimum length before prefix matching is used.
`MIN_FUZZY_TERM_LENGTH`	`4`	Minimum term length before tolerant fuzzy matching may activate.
`STEP_PREVIEW_MAX_LINES`	`6`	Step preview/UI threshold used in result rendering logic.
`STEP_TOGGLE_MIN_LENGTH`	`220`	Length threshold used for step expansion behavior.
`COPY_SUMMARY_PREVIEW_LENGTH`	`200`	Maximum number of characters included in summarized copy mode previews.
`CONTROLS_POPOVER_OFFSET`	`8`	Vertical spacing between the popover trigger and the popover.
`CONTROLS_POPOVER_CLOSE_DELAY_MS`	`220`	Delay before close-enabled popover actions close the menu.
`LINKING_ENABLED`	`true`	Enables deep-link/navigation behavior in result links.

Related configuration objects:

FILTER_OPTIONS
SEARCH_MODE_OPTIONS
SEARCH_LOGIC_OPTIONS
DEFAULT_SEARCH_BOOST
ID_SEARCH_BOOST

Build setup

The build uses Vite with:

vite-plugin-singlefile
vite-plugin-minify

Current behavior from vite.config.js:

injects __APP_VERSION__ from package.json
builds a single-file output
disables module preload
leaves Vite’s internal minifier off because minification is handled by the plugin configuration

Scripts

Available npm scripts from package.json:

npm run dev
- starts Vite development mode
npm run build
- production build
npm run build-mbs
- production helper build script
npm run build-release
- release build script
npm run upload
- upload helper for FileMaker integration
npm run deploy-to-fm
- runs build and upload together

Requirements

Node.js: >=22

Summary

This project is a single-file, browser-based search tool for FileMaker/MBS script XML. It supports:

exact and tolerant search logic
all-term and any-term matching
optional case-sensitive search
category filters with counts
grouped result browsing
collapse/expand controls
summarized or full clipboard export
native popover-based actions
client-side indexing with MiniSearch

If you want to change how the search feels, the first place to check is src/scriptSearchApp.js, especially the search option arrays, the matching helpers, the score boosts, and the constants listed above.